The Secure Shell (SSH) protocol allows client computers to connect with servers to perform services such as remote login, file transfer, file copy and other secure network services over an insecure network such as the Internet. With an SSH connection, passwords are encrypted so that account and group authentication credentials are protected. FIG. 1A is a block diagram of a portion of the Open Systems Interconnection (OSI) model established by the International standards organization (ISO) depicting layers involved in a conventional SSH establishment process. The SSH protocol 10 is employed to establish a secure remote login between a client 30 and a server 70. The client 30 includes a computer platform 12 having a transmission control protocol/Internet protocol (“TCP/IP”) connection 14, or other comparable data stream connection. Correspondingly, the server 70 includes a computer platform 52 having a TCP/IP connection 54.
In general, the SSH protocol 10 securely connects client 30 and server 70 by establishing a session key between transport layers 16, 56 of the client and server, respectively. The transport layer protocol provides server authentication, confidentiality, and integrity. Once the session key is established, a user authentication protocol authenticates the client user authentication layer 18 to the server authentication layer 58. The user authentication protocol supports various encryption methodologies, including public key, password and host-based client methods. An encrypted tunnel is then multiplexed between the client connection layer 20 and the server connection layer 60.
The SSH protocol, which is described by various Internet drafts from the (IETF), including “SSH Protocol Architecture,” “SSH Transport Layer Protocol,” “SSH Authentication Protocol,” and “SSH Connection Protocol.” These documents are Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Protocol Architecture”, RFC 4251, January 2006, and Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Transport Layer Protocol”, RFC 4253, January 2006, Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Authentication Protocol”, RFC 4252, January 2006, and Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Connection Protocol”, RFC 4254, January 2006, all of which are incorporated by reference herein. While these drafts provide various standards for the SSH protocol, there is no definitive security policy established that sets forth procedures by which a server, presented with a request by a client computer to establish an authenticated and protected tunnel over which to run an SSH service, authorizes such a request. This has resulted in substantial management obstacles for enterprises that require employees, consultants and/or vendors to access network resources using an SSH connection. Conventionally, implementers must maintain, at each server, authorization policies for individual clients and accounts, i.e., users and applications.
In addition, SSH providers include various vendors and/or open source entities. The multiplicity of providers generally results in implementation of diverse authorization protocols. One known authorization protocol allows a user, once authenticated, to use all resources available through the SSH connection. This clearly presents security problems in enterprises where different accounts are provided for access to specified network information.
A common approach to existing SSH security policy management and enforcement is the implementation of configuration files at each server using the SSH daemon, i.e., a server-centric approach. One attempt to enhance security policies with respect to an individual server operating in an SSH protocol is described in Hemsath U.S. Pat. No. 6,851,113, assigned to IBM, and which is incorporated by reference herein. In the Hemsath patent, an extension is provided on an SSH server whereby a set of user credentials are created, and the credentials are associated with a session key. While Hemsath states that a policy database of allowed users and permissions is preferably maintained in a centralized location for ease of administration, this is referring only to a centralized user registry on the particular server. However, Hemsath is not in any way concerned with problems that arise when several target servers operating in the SSH protocol are to be administered.
FIG. 1B is a flow diagram of an account authorization process on a server-centric level according to the prior art. The process starts 202 after the SSH session key has been established between the transport layers of the client computer and the server. This protects account information transmitted over the connection, including account names and passwords. The first decision step 204 queries the server as to whether the account is authenticated according to the existing authentication protocol of the SSH standards. If the account is not authenticated, then the establishment of the requested SSH tunnel is rejected 218.
If the account is authenticated, the process then proceeds to a series of steps to authorize the user based on a server-centric user registry or configuration file. A processing step 206 is invoked, in which the source, i.e., client computer, is identified. The next decision step 208 determines whether the account is allowed. In conventional SSH authorization protocols, this step generally assumes that the account is allowed to access the target server from any source computer unless a particular source is specified. If the decision at step 208 is affirmative, i.e., the account does not specify a particular source computer, then the SSH session is established 216.
If the decision at step 208 is negative, then the next decision step 210 determines whether the account access is permitted from the particular source based upon consultation with the server-centric user registry. If the decision at step 210 is affirmative, then the SSH session is established 216.
If the decision at step 210 is negative, the process flow proceeds to a primary group identification step 212, in which the primary group membership for the user is obtained. The primary group membership is used to determine at decision step 214 whether the identified group is allowed based on group permission retained in the user registry stored in the target server. If the decision 214 is affirmative, then the SSH session is established 216 without restriction based on the source identity. If the decision at step 214 is negative, establishment of the SSH session is rejected 218.
While a server-centric policy management system generally following the authorization process described with respect to FIG. 1B can be acceptable for systems with one server operating the SSH protocol, it has been found that relying upon individual server administration policies in organizations operating a plurality of servers is rather cumbersome. Many enterprises operate several hundred, or more, servers, with resources accessed from many thousands of client computers. Configuration files containing specific policies must be specified or replicated at each server, requiring updates on a regular basis and/or when accounts are changes. This is difficult, if not impossible, to implement on a real time basis, and hence the likelihood of error is increased.
Further, by using server-centric security administration policies, each server itself is a so-called “weak link” that can be compromised. If a particular server having the configuration files is compromised, an intruder could not only access data at that server, but could also modify the configuration file and/or the user registry thereby facilitating future intrusions.
Active Directory is a directory service component to Windows® server platforms, and provides the means to manage the identities and relationships within and among Windows® servers. However, many servers employ operating systems other than Windows®, such as UNIX or Linux operating systems. The Active Directory identity management tools are not compatible with operating systems other than Windows®. A key disadvantage of this limitation is that the Active Directory identity management tools will only work within a homogenous Windows® operating system environment.
It would, therefore, be desirable to have an access management system for managing access by client computers to servers which is independent of the operating system being run in each server, which reduces the conflicting access policies in different servers and which increases the security of the access policies.